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ABSTRACT 

TAME  is  a  special-purpose  interface  to  PVS  designed  to 
support  developers  of  software  systems  in  proving  proper¬ 
ties  of  automata  models.  One  of  TAME’s  major  goals  is 
to  allow  a  software  developer  who  has  basic  knowledge  of 
standard  logic,  and  can  do  hand  proofs,  to  use  PVS  to  rep¬ 
resent  and  to  prove  properties  about  an  automaton  model 
without  first  becoming  a  PVS  expert.  A  second  goal  is  for 
a  human  to  be  able  to  read  and  understand  the  content 
of  saved  TAME  proofs  without  running  them  through  the 
PVS  proof  checker.  A  third  goal  is  to  make  proving  prop¬ 
erties  of  automata  with  TAME  less  costly  in  human  time 
than  proving  such  properties  using  PVS  directly.  Recent 
work  by  Rornijn  and  Devillers  et  al.,  based  on  the  I/O  au¬ 
tomata  model,  has  provided  the  basis  for  two  case  studies  on 
how  well  TAME  achieves  these  goals.  Rornijn  specified  the 
RPC-Memory  Problem  and  its  solution,  while  Devillers  et 
al.  specified  a  tree  identify  protocol.  Hand  proofs  of  specifi¬ 
cation  properties  were  provided  by  the  authors.  In  addition, 
Devillers  et  al.  used  PVS  directly  to  mechanize  the  specifi¬ 
cations  and  proofs  of  the  tree  identify  protocol.  In  one  case 
study,  the  third  author,  a  new  TAME  user  with  no  previous 
PVS  experience,  used  TAME  to  create  PVS  specifications  of 
the  I/O  automata  presented  by  Rornijn  and  Devillers  et  al. 
and  to  check  the  hand  proofs  of  invariant  properties.  The 
PVS  specifications  and  proofs  of  Devillers  et  al.  provide  the 
basis  for  the  other  case  study,  which  compares  the  TAME 
approach  to  an  alternate  approach  which  uses  PVS  directly. 
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1.  INTRODUCTION 

Several  authors  [25,  8,  9,  7]  have  found  that  the  PVS  spec¬ 
ification  language  and  similar  strongly  typed,  higher-order 
logic  languages  are  well  suited  to  the  formalization  of  sys¬ 
tem  specifications.  All  report  that  appropriately  structured 
PVS  specifications  can  be  understood  by  practitioners,  such 
as  design  engineers  and  requirements  analysts. 

Yet,  a  number  of  barriers  exist  to  more  widespread  indus¬ 
trial  use  of  formal  techniques  such  as  PVS.  Although  Miller 
notes  in  [25]  that  engineers  at  Collins  Aviation  learned  to 
use  PVS,  the  authors  of  each  of  [25,  8,  9,  10]  concede  that  in 
general  practitioners  themselves  may  be  unwilling  or  unable 
to  create  formal  specifications  or  to  perform  analysis  of  the 
specifications  using  the  PVS  proof  checker.  Further,  But¬ 
ler  et  al.  [8]  observe  that  one  barrier  to  transferring  formal 
methods  technology  to  industry  is  that: 

Training  the  industrial  experts  to  use  the  formal 
techniques,  especially  to  develop  skill  in  verifica¬ 
tion,  [is  costly]. 

The  high  cost  of  training  industrial  experts  is  not  the  sole 
barrier  to  more  general  use  of  PVS  (or  other  theorem  proving 
systems)  to  formalize  and  to  prove  properties  of  specifica¬ 
tions.  For  a  given  system,  a  user  must  discover  an  appro¬ 
priate  representation  in  the  language  of  the  theorem  prover. 
Formal  proofs  of  system  properties  will  be  influenced  by  the 
details  of  the  representation,  the  particular  reasoning  steps 
available  in  the  theorem  prover,  and  the  manner  in  which 
the  properties  are  formalized.  The  effort  required  therefore 
is  substantial  even  for  those  who  have  mastered  the  use  of 
the  theorem  prover.  Moreover,  direct  use  of  any  general 
theorem  prover  can  encourage  users  to  adapt  both  specifi¬ 
cations  and  proofs  to  the  needs  of  the  prover  rather  than  to 
the  conventions  associated  with  the  problem  domain.  As  a 
result,  practitioners  may  find  it  difficult  to  relate  the  formal¬ 
ization  of  their  system  and  formal  proofs  of  its  properties  to 
their  understanding  of  the  system  behavior  and  their  beliefs 
as  to  why  it  lias  certain  properties.  We  agree  with  Butler  et 
al.  [8]  when  they  state  that: 

[T]lie  formal  methods  researchers  must  be  willing 
to  adapt  their  methods  to  the  problem  domain 
rather  than  fight  to  change  the  existing  method¬ 
ologies  to  conform  to  their  needs. 

TAME  (Timed  Automata  Modeling  Environment)  [3,  5,  6, 
2]  is  a  specialized  interface  to  PVS  that  is  intended  to  re- 
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move,  or  at  least  reduce,  the  barriers  to  more  general  use 
of  PVS  in  verifying  automata  models.  It  supports  the  cre¬ 
ation  of  PVS  descriptions  of  three  different  automata  mod¬ 
els:  Lynch- Vaandrager  (LV)  timed  automata  [23],  I/O  au¬ 
tomata  [21],  and  the  automata  model  that  underlies  SCR 
specifications  [16].  Further,  TAME  supports  formulating 
properties  of  these  automata  in  standard  logic  and  proving 
the  properties  using  reasoning  “natural”  to  humans.  A  ma¬ 
jor  goal  of  TAME  is  to  improve  on  the  direct  support  that 
PVS  provides  for  specifying,  and  proving  properties  of,  au¬ 
tomata.  To  make  PVS  specifications  of  automata  easy  to 
create  from  automaton  descriptions,  TAME  provides  tem¬ 
plates  for  specifying  automata.  To  make  PVS  proofs  of 
properties  of  automata  easy  to  create,  TAME  provides  PVS 
strategies  which  support  the  kinds  of  proof  steps  normally 
found  in  hand  proofs  of  invariant  properties  of  automata. 
In  particular,  TAME  is  intended  to  support  straightforward 
construction  of  a  mechanized  proof  of  an  invariant  property 
from  a  high  level  hand  proof  that  expresses  an  application 
expert’s  explanation  of  why  the  property  should  hold. 

In  recent  work  by  Romijn  [28,  27]  and  Devillers  et  al.  [12, 
11],  example  systems  to  be  implemented  in  software  were 
specified  and  verified  using  the  I/O  automata  model.  This 
work,  together  with  the  availability  of  a  volunteer  TAME 
user  with  no  previous  PVS  experience  (the  third  author), 
gave  us  an  opportunity  to  evaluate  the  extent  to  which 
TAME  has  achieved  its  goals.  Both  [28]  and  [12]  provide 
descriptions  of  I/O  automata  and  formulations  of  their  prop¬ 
erties.  References  [27]  and  [11]  provide  hand  proofs  of  most 
of  the  properties  in  [28]  and  [12]  in  varying  degrees  of  detail. 
Thus,  the  third  author  had  several  example  specifications 
and  proofs  to  which  she  could  apply  TAME.  In  addition,  ref¬ 
erence  [12]  describes  the  PVS  specification  and  proofs  for  one 
application,  an  I/O  automaton  called  TIP ,  with  a  pointer 
to  the  actual  specification  and  proofs  on  the  web.  This  gave 
us  the  opportunity  to  compare  the  use  of  TAME  with  the 
more  direct  use  of  PVS  on  one  particular  problem. 

Section  2  of  this  paper  provides  a  high  level  description  of 
TAME,  its  templates,  and  its  strategies.  Section  3  then  com¬ 
pares  the  PVS  approach  to  specification  and  proof  for  TIP 
[12]  to  the  TAME  approach  to  the  same  problem.  (Although 
this  case  study  was  done  after  the  study  of  TIP  by  the  third 
author  discussed  in  Section  4,  we  describe  it  first  because  it 
clarifies  the  difference  between  using  PVS  through  TAME 
and  using  PVS  directly.)  Section  4  describes  the  experi¬ 
ence  of  the  third  author  in  applying  TAME  to  the  examples 
of  references  [28,  27,  12,  11],  with  particular  attention  to 
1)  the  time  and  effort  required  and  2)  the  adequacy  of  the 
TAME  proof  steps  for  mechanizing  the  proofs  of  invariants. 
Section  5  discusses  the  results  of  Sections  3  and  4  and  de¬ 
scribes  some  improvements  in  TAME  that  resulted  from  the 
case  study  in  Section  4.  Finally,  Section  6  describes  related 
work,  and  Section  7  presents  our  conclusions. 

2.  TAME 

For  software  developers  in  industry,  model  checking  is  often 
viewed  as  more  practical  than  theorem  proving  for  estab¬ 
lishing  properties  of  software  systems.  While  clearly  an  im¬ 
portant  technique  for  developing  correct  software  systems, 
model  checking  does  not  solve  all  of  a  software  developer’s 
problems.  For  example,  although  model  checking  is  often 
described  as  automatic  and  therefore  requiring  less  exper¬ 


tise  from  the  user,  the  user,  due  to  the  state  explosion  prob¬ 
lem,  must  typically  model  check  an  abstraction  of  a  given 
system  rather  than  the  full  system.  Finding  the  appropri¬ 
ate  abstraction  often  requires  user  ingenuity  and  creativ¬ 
ity.  Even  when  abstraction  is  used,  state  explosion  can  pre¬ 
vent  a  model  checker  from  running  to  completion,  and  thus 
from  establishing  the  correctness  of  a  property.  Moreover, 
in  specifications  involving  parameters,  model  checking  alone 
can  only  check  correctness  for  specific  (usually  small),  rather 
than  arbitrary,  values  of  the  parameters.  The  protocols  from 
[28]  and  [12]  involve  both  parameters  and  another  feature — 
complex  data  types — problematic  for  a  model  checker.  Thus, 
for  the  verification  of  these  and  similar  examples,  theorem 
proving  is  necessary. 

TAME  is  intended  to  reduce  the  human  effort  associated 
with  mechanical  theorem  proving  using  PVS.  To  achieve 
this,  TAME  provides  an  interface  to  PVS  [3,  5,  6,  2].  This 
interface  consists  of  a  set  of  templates  for  specifying  au¬ 
tomata,  a  set  of  standard  theories,  and  a  set  of  standard 
PVS  strategies.  Below,  we  provide  an  overview  of  the  tem¬ 
plates,  theories,  and  strategies,  and  how  they  are  related. 
We  also  discuss  the  major  goals  which  have  guided  the  de¬ 
sign  of  the  TAME  strategies. 

TAME  Templates.  TAME  currently  provides  templates 
for  each  of  the  three  classes  of  automata  mentioned  in  Sec¬ 
tion  1:  LV  timed  automata,  I/O  automata,  and  SCR  au¬ 
tomata.  Each  template  provides  a  standard  structure  for 
defining  an  automaton.  Because  LV  timed  automata  are 
essentially  I/O  automata  with  time  added,  the  template 
originally  designed  for  specifying  LV  timed  automata  was 
easily  adapted  to  specifying  I/O  automata.  To  define  an 
automaton  of  either  of  these  two  classes,  the  user  provides 
the  information  indicated  in  Figure  1. 


Template  Part 

User  Fills  In 

Remarks 

actions 

Declarations  of 
non-time-passage  actions 

The  nondefault  cases  of  the 
actions  datatype 

MMTstates 

Type  of  the  “basic  state” 
representing  the  state  variables 

Usually  a  record  type 

OKstate? 

An  arbitrary  state  predicate 
restricting  the  set  of  states 

Default  is  true 

enabled_specif ic 

Preconditions  for  all  the 
non-time-passage  actions 

enabled_specif ic (a)  = 
specific  precondition  of  action  a 

trans 

Effects  of  all  the  actions 

trans  (a,  s)  =  state  reached 
from  state  s  by  action  a 

start 

State  predicate  defining  the 
initial  states 

Preferred  forms:  s  =  ...  or 
s  =  (#  basic  :=  basic  (s) 
WITH  . . . 

...  #) 

const_facts 

Predicate  describing  relations 
assumed  among  the  constants 

Optional 

Figure  1:  Information  in  the  TAME  template 

Specifications  of  I/O  automata  in  the  style  used  by  Devillers 
et  al.  [12]  and  Romijn  [28]  (see  Appendix  A  for  an  exam¬ 
ple)  can  be  easily  translated  into  TAME  specifications.  The 
definitions  of  the  actions  of  the  I/O  automaton  provide  the 
names  and  argument  types  needed  for  their  TAME  declara¬ 
tions,  preconditions  and  effects.  The  definitions  of  the  state 
variables  and  their  types  in  the  I/O  automaton  specification 
provide  the  information  needed  to  define  the  type  of  the  ba¬ 
sic  state  as  well  as  any  needed  auxiliary  type  definitions 
in  the  TAME  specification.  The  initial  state  information 
for  the  I/O  automaton  is  translated  into  the  initial  state 
predicate  start  of  the  TAME  specification.  Finally,  any 
constants  and  predicates  relating  constants  defined  for  the 
I/O  automaton  can  be  represented  in  the  TAME  specifica- 


tion  using  constant  declarations  and  the  axiom  const_f  acts. 
TAME  does  not  provide  automated  support  for  composing 
automata  or  reasoning  directly  about  an  automaton  defined 
as  a  composition.  However,  when  an  I/O  automaton  is  de¬ 
fined  as  the  composition  of  two  or  more  other  I/O  automata 
(this  happens  with  some  of  the  automata  in  [28]),  the  user 
can  combine  the  information  extracted  from  the  individual 
automaton  descriptions  to  produce  a  single  TAME  specifi¬ 
cation  in  a  (usually)  straightforward  way. 

TAME  Proof  Steps.  The  standard  strategies  of  TAME 
are  designed  to  support  mechanical  reasoning  about  au¬ 
tomata  using  proof  steps  that  mimic  human  proof  steps. 
These  strategies  are  based  on  type  and  name  conventions  en¬ 
forced  by  the  templates,  the  TAME  standard  theories,  and 
additional  special  definitions,  auxiliary  local  theories,  and 
local  strategies  that  can  be  generated  from  a  particular  tem¬ 
plate  instantiation.  For  example,  lemmas  in  the  standard 
theory  machine  support  the  induction  strategy  AUTO-IN¬ 
DUCT  (see  Figure  2).  The  auxiliary  local  theories  contain 
lemmas  used  to  support  rewriting  and  forward  chaining  need¬ 
ed  in  “obvious”  reasoning  about  the  particular  application. 

Reference  [2]  lists  the  TAME  user  strategies  useful  for  I/O 
and  LV  automata,  and  describes  their  effects.  These  strate¬ 
gies  implement  proof  steps  typically  used  in  hand  proofs 
of  automaton  properties.  Hand  proofs  of  invariant  proper¬ 
ties  typically  contain  only  proof  steps  from  a  limited  set. 
Figure  2  lists  the  most  common  proof  steps  used  in  invari¬ 
ant  proofs  and  names  the  TAME  strategies  that  implement 
them.  TAME  strategies  also  exist  for  several  steps  needed 
less  frequently  than  those  listed  in  Figure  2. 


Proof  Step 

TAME  Strategy 

Remarks 

Break  down  into  base  case  and 
induction  (i.e.,  action)  cases,  and 
do  standard  first  steps  of  each  case 

AUTO_INDUCT 

For  starting  an 
induction  proof 

Appeal  to  precondition  of  an 
action 

APPLY_SPECIFIC_PRECOND 

Used  when  needed 
in  induction  cases 

Apply  the  inductive  hypothesis 
to  argument(s)  other  than  the 
(default)  skolem  constant(s) 

APPLY_IND_HYP 

Used  when  needed 
in  induction  cases; 
needs  argument(s) 

Perform  the  standard  initial  steps 
in  the  direct  proof  of  an  invariant 

DIRECT_PROOF 

For  starting  a 
non-induction  proof 

Apply  an  auxiliary  invariant 
lemma 

APPLY_INV_LEMMA 

Used  in  any  proof; 
needs  argument(s) 

Break  down  into  cases  based 
on  a  predicate 

SUPPOSE 

Used  in  any  proof; 
needs  boolean  argument 

Apply  “obvious”  reasoning,  e.g., 
propositional,  equational,  datatype 

TRY_SIMP 

Used  for  “it  is  now 
obvious”  in  any  proof 

Use  a  fact  from  the  mathematical 
theory  for  a  state  variable  type 

APPLY_LEMMA 

Used  in  any  proof; 
needs  argument(s) 

Figure  2:  Common  steps  for  invariant  proofs  and 
their  TAME  strategies1 

Major  Goals  of  the  TAME  Proof  Steps.  One  ma¬ 
jor  goal  of  the  TAME  proof  steps  is  to  save  the  user  from 
much  of  the  tedium  typical  of  proofs  done  directly  in  PVS. 
One  technique  for  achieving  this  (used  in  almost  all  of  the 
TAME  strategies)  is  to  incorporate  repeated  patterns  of 
steps.  Several  repeated  patterns  are  incorporated  into  the 
TAME  strategy  AUTO-INDUCT.  In  some  cases,  a  re¬ 
peated  pattern  becomes  a  single  proof  step.  For  example, 
the  TAME  strategy  called  APPLY JNV.LEMMA,  with 
the  appropriate  arguments,  introduces  the  desired  invari¬ 
ant  lemma,  instantiates  it,  expands  the  invariant,  and  dis- 

1Here  and  below,  a  name  in  bold  capital  letters  denotes  a 
TAME  strategy. 


charges  the  reachability  condition  that  is  the  hypothesis  of 
the  lemma.  Another  technique  TAME  uses  to  eliminate  te¬ 
dium  is  to  automate  certain  inferences  which  are  “obvious” 
to  humans  but  which,  in  PVS,  require  detailed  user  guidance 
together  with  knowledge  of  the  behavior  and  some  of  the 
more  obscure  proof  steps  of  the  PVS  prover.  Several  such 
inferences  relate  to  the  PVS  DATATYPE  construct.  For 
example,  if  con  and  des  are  a  corresponding  constructor- 
destructor  pair  in  a  datatype  A,  it  is  obvious  to  a  human 
that  con(des(a))  =  a  whenever  a  is  a  “con”  value  of  A. 
To  establish  this  needed  fact  in  a  proof,  the  PVS  user  must 
apply  the  PVS  step  APPLY-EXTENSIONALITY.  Estab¬ 
lishing  other  simple  facts  about  data  types  can  require  the 
PVS  steps  REPLACE  and  CASE  to  do  explicit  substitution 
and  judicious  case  splitting.  The  auxiliary  local  theories 
that  can  be  generated  from  a  template  instantiation  provide 
the  conditional  rewrite  rules  and  lemmas  used  by  the  TAME 
strategy  TRY_SIMP  to  make  such  inferences  automatic. 

A  second  major  goal  of  the  TAME  proof  steps  is  to  make 
saved  PVS  proofs  understandable  by  humans  without  exe¬ 
cuting  them  in  PVS.  Saved  TAME  proofs  have  a  clear  struc¬ 
ture,  with  the  meanings  of  the  proof  branches  indicated  by 
comments  automatically  generated  by  TAME.  The  mean¬ 
ings  of  the  individual  TAME  proof  steps  can  be  inferred  from 
their  names  and  arguments.  In  verbose  mode,  TAME  prints 
extended  comments  showing  the  exact  facts  introduced,  so 
that  the  reader  of  a  proof  does  not  need  to  look  up  partic¬ 
ular  lemmas,  preconditions,  etc.  (Sections  3  and  5  contain 
example  TAME  proofs.) 

Finally,  the  TAME  proof  steps  are  designed  to  give  users  im¬ 
proved  feedback  from  PVS  in  the  course  of  a  proof,  through 
appropriate  labels  on  formulae  that  indicate  their  origin, 
and  hence  their  significance.  For  example,  the  strategy 
AUTO-INDUCT  labels  formulae  in  subgoals  correspond¬ 
ing  to  induction  cases  according  to  whether  they  come  from 
the  precondition,  inductive  hypothesis,  or  inductive  conclu¬ 
sion,  or  express  the  fact  that  the  prestate  or  poststate  of  an 
induction  step  is  reachable.  When  the  TAME  step  SUP¬ 
POSE  is  applied  to  an  assertion  argument  P,  the  current 
subgoal  will  be  split  into  two  subgoals,  one  with  the  hypoth¬ 
esis  P  labeled  Suppose  and  the  other  with  the  hypothesis 
not(P)  labeled  Suppose  not.2  Facts  introduced  with  AP¬ 
PLY  _INV -LEMMA  or  APPLYTEMMA  will  be  given 
a  label  lemma  <lemma-name>  derived  from  the  name  of  the 
lemma.  In  later  subgoals,  the  descendants  of  a  labeled  for¬ 
mula  retain  the  labels  of  their  parent  and  are  thus  useful  in 
indicating  the  reason  for  the  presence  of  new  formulae.  The 
ability  to  label  formulae,  a  recent  new  feature  of  PVS,  is 
important  in  the  execution  of,  as  well  as  the  feedback  from, 
the  TAME  strategies. 

3.  FIRST  CASE  STUDY 

Reference  [12]  describes  the  direct  use  of  PVS  to  mechanize 
the  proofs  of  properties  of  an  automaton  called  TIP ,  a  tree 
identify  protocol.  Below,  we  contrast  the  TAME  approach 
with  the  direct  PVS  approach,  drawing  from  the  third  au¬ 
thor’s  results  from  applying  of  TAME  to  TIP.  For  brevity, 

2  Technically,  because  PVS  does  not  allow  negative  formu¬ 
lae  to  appear  at  the  top  level  of  a  sequent,  the  hypothesis 
“not(P)”  in  the  “Suppose  not”  subgoal  will  appear  as  “P” 
in  the  “wrong  half”  of  the  sequent  (assuming  P  itself  is  not 
a  negation). 


To  prove:  For  every  reachable  state  s,  for  every  edge  e, 
length  (mq  (e,  s ))  <=  1. 

Proof:  The  proof  is  by  induction.  The  assertion  is  trivial  for  the  base  case,  i.e.,  when  s 
is  an  initial  state.  For  each  action  of  TIP,  it  remains  to  prove  the  corresponding  induction 
case,  i.e.,  that  the  assertion  is  preserved  by  that  action.  Only  three  of  the  induction  cases 
are  nontrivial. 

Case  1:  The  action  add_child(addE) .  Let  the  value  of  the  parameter  addE  of 
add_child  be  addE_action,  and  consider  the  edge  e_theorem.  First,  apply  the 
specific  precondition  of  add_child  (addE_action) .  Then,  consider  separately  the 
cases  e_theorem  =  addE_action  and  e_theorem  ^  addE_action.  In  each 
of  these  cases,  the  proof  is  now  obvious. 

Case  2:  The  action  children_known  (childV) .  Let  the  value  of  the  parameter 
childV  of  children_known  be  childV_action,  and  consider  the  edge 
e_theorem.  Consider  separately  two  cases.  Suppose  first  that 
source  (e_theorem)  =  childV_action.  In  this  case,  first  appeal  to  the  specific 
precondition  of  children_known  (childV_action)  and  then  apply  Invariant  /2 
in  the  prestate  to  e_theorem.  The  remainder  of  the  proof  in  this  case  is  now  obvious. 
The  proof  in  the  case  source  (e_theorem)  ^  chi ldV_act  ion  is  obvious. 

Case  3:  The  action  ack(ackE).  Let  the  value  of  the  parameter  ackE  of  ack  be 
ackE_action,  and  consider  the  edge  e_theorem.  Consider  separately  two  cases. 
Suppose  first  that  e_theorem  =  ackE_action.  Appeal  to  the  specific  precondition 
of  ack  (ackE_action) .  The  proof  in  this  case  is  now  obvious.  The  proof  in  the  case 
e_theorem  ^  ackE_action  is  obvious. 


Figure  3:  Natural  Language  Proof  of  Invariant  1 5 

we  refer  to  “TAME”  specifications  and  proofs  and  “PVS” 
specifications  and  proofs. 

Comparing  Proofs  of  Invariants.  The  most  dramatic 
difference  between  the  PVS  approach  of  [12]  and  the  TAME 
approach  is  in  the  proofs  of  invariants.  The  TAME  proofs 
are  much  shorter,  and  the  significance  of  proof  branches  and 
individual  proof  steps  is  much  clearer.  Moreover,  the  TAME 
proofs  correspond  in  a  very  clear  way  to  the  hand  proofs  in 

[11] .  In  fact,  the  TAME  proofs  for  those  TIP  invariants 
for  which  hand  proofs  were  provided  were  done  by  refer¬ 
ring  to  the  hand  proofs.  (See  Section  5  for  more  details.) 
This  method  differs  from  the  method  used  by  the  authors  of 

[12] ,  who  found  the  hand  proofs  of  little  use  in  guiding  their 
mechanization  in  PVS,  and  did  not  try  to  follow  them. 

Proofs  in  general  have  a  natural  tree  structure.  Branching 
occurs  when  the  proof  breaks  into  cases  or  when  extra  proof 
obligations  are  created  by  a  proof  step.  When  a  user  creates 
a  proof  interactively  in  PVS,  PVS  saves  an  executable  script 
of  the  proof,  recording  both  the  proof  steps  invoked  by  the 
user  and  the  branching  structure  of  the  proof.  In  the  ex¬ 
ample  TAME  and  PVS  proofs  in  this  paper,  the  proof  steps 
supplied  by  the  user  are  in  Roman  font  with  the  names  of 
TAME  strategies  in  bold,  and  the  parts  of  the  proof  scripts 
created  by  PVS  are  in  italics.  The  italic  numbers  in  quotes 
represent  the  addresses  of  the  proof  branches  in  the  tree 
and  hence  show  the  tree  structure.  The  TAME  proofs  also 
include  comments  (in  italics  and  preceded  by  semicolons) 
automatically  generated  by  the  TAME  strategies. 

The  resemblance  of  TAME  proofs  to  hand  proofs  is  illus¬ 
trated  by  the  natural  language  proof  of  TIP  Invariant  I5 
in  Figure  3.  This  proof  was  obtained  by  hand  translating 
the  TAME  proof  of  I5  in  Figure  4  in  a  straightforward  way. 
Although  the  hand  proof  from  which  the  TAME  proof  of 
I5  was  derived  was  a  Lamport-style  proof  [18]  rather  than 
a  natural  language  proof,  TAME  proofs  can  also  be  (and 
have  been)  derived  from  natural  language  proofs  providing 
the  level  of  detail  of  the  proof  in  Figure  3. 

Figure  5  presents  the  PVS  proof  of  TIP  Invariant  I5  de¬ 
veloped  by  Devillers  et  al.  [12].  As  the  translation  in  Fig- 


Inv_5(s:states):  bool  =  (FORALL  (e:Edges):  length! mq(e,s))  <=  1); 

("" 

(AUTO_INDUCT) 

(("I "  ;;Case  add_child(addE_action) 

(APPLY_SPECIFIC_PRECOND) 

(SUPPOSE  "e_theorem  =  addE_action") 

(("1.1" ;; Suppose  e_theorem  =  addE_action 
(TRYjSIMP)) 

("1.2" ;; Suppose  not  [e_theorem  =  addE_action] 

(TRYjSIMP)))) 

("2"  ;;Case  children_known(childV_action) 

(SUPPOSE  "source(e_theorem)  =  childV_action") 

(("2.1" ;; Suppose  source(e_theorem)  =  childV _action 

(APPLY_SPECIFIC_PRECOND) 

->  (APPLY_INV_LEMMA  "2"  "e_theorem") 

(TRYJSIMP)) 

("2.2"  ;;Suppose  not  [source(e_theorem)  =  childV _action] 
(TRYjSIMP)))) 

("3"  ;;Case  ack(ackE_action) 

(SUPPOSE  "e_theorem  =  ackE_action") 

(("3.1" ;;  Suppose  e_theorem  =  ackE_action 
(APPLY_SPECIFIC_PRECOND) 

(TRYjSIMP)) 

("3.2" ;; Suppose  not  [e_theorem  =  ackE_action] 

(TRYjSIMP)))))) 


Figure  4:  TAME  Proof  of  Invariant  is 


INV_5((s:  states)):  bool  =  (FORALL  (e:  E):  length(mq(s)(e))  <=  1 ) 


(EXPAND  "invariant?") 

("2. 1.1. 3"  (ASSERT)))) 

(ASSERT) 

(PROP) 

("2.1.2"  (INST?)))) 

(INST?) 

(("1" 

("2.2" 

(("2.3. 1.1.1" 

(SKOSIMP*) 

(SKOSIMP*) 

(EXPAND  "member") 

(EXPAND  "INV_5") 

(EXPAND  "steps") 

(EXPAND  "froms") 

(SKOLEM!) 

(EXPAND  "ACK_step") 

(ASSERT) 

(EXPAND  "Init") 

(PROP) 

(HIDE  -2  -3  -4) 

(PROP) 

(REPLACE  -1  :HIDE?  T) 

(INST?) 

(HIDE  -1) 

(EXPAND  "INV_5") 

(EXPAND  "append") 

(INST?) 

(SKOSIMP*) 

(EXPAND  "length"  1) 

(PROP) 

(LIFT-IF) 

(EXPAND  "length") 

(HIDE  I) 

(PROP) 

(ASSERT)) 

(EXPAND  "length") 

(("2.2.1" 

("2.3.1. 1.2" 

(ASSERT)) 

(INST?) 

(EXPAND  "tos") 

("2" 

(ASSERT) 

(EXPAND  "target") 

(SKOLEM  1  (S  _  T)) 

(HIDE -1  2  3) 

(EXPAND  "inv") 

(INDUCT  "a"  1) 

(EXPAND  "tl") 

(EXPAND  "member") 

(("2.1" 

(EXPAND  "length") 

(EXPAND  "froms") 

(SKOSIMP*) 

(LIFT-IF) 

(PROPAX)))) 

(EXPAND  "steps") 

(PROP) 

("2.3. 1.2" 

(EXPAND  "A_C_step") 

(("2.2. 1.1"  (ASSERT)) 

(EXPAND  "tos") 

(PROP) 

("2.2. 1.2"  (ASSERT) 

(EXPAND  "member") 

(REPLACE  -2  :HIDE?  T) 

(EXPAND  "length") 

(EXPAND  "froms") 

(EXPAND  "INV_5") 

(LIFT-IF) 

(EXPAND  "inv") 

(SKOSIMP*) 

(ASSERT)))) 

(EXPAND  "target") 

(LIFT-IF) 

("2.2.2"  (INST?)))) 

(PRO  PAX)))) 

(PROP) 

("2.3" 

("2.3.2"  (HIDE  -2)  (INST?)))) 

(("2.1.1" 

(SKOSIMP*) 

("2.4"  (SKOSIMP*) 

(INST?) 

(EXPAND  "steps") 

(EXPAND  "steps") 

(REPLACE  -1  :HIDE?  T) 

(EXPAND  "C_K_step") 

(EXPAND  "R_C_step") 

(HIDE-1) 

(PROP) 

(PROP) 

(HIDE  2) 

(REPLACE  -3  :HIDE?  T) 

(REPLACE  -3  :HIDE?  T) 

(EXPAND  "tl") 

(EXPAND  "INV_5") 

(EXPAND  "INV_5") 

(EXPAND  "length") 

(SKOSIMP*) 

(PROPAX)) 

(ASSERT) 

(LIFT-IF) 

("2.5" 

(LIFT-IF) 

(PROP) 

(SKOSIMP*) 

(PROP) 

(("2.3.1" 

(EXPAND  "steps") 

(ASSERT) 

(INST?) 

(EXPAND  "ROOT_step") 

(EXPAND  "length") 

(("2.3.1. 1" 

(PROP) 

(LIFT-IF) 

(ASSERT) 

(REPLACE  -2  :HIDE?  T) 

(PROP) 

(USE  "INV_2_reach") 

(EXPAND  "INV_5") 

(("2. 1.1.1"  (ASSERT)) 

->  (EXPAND  "INV_2") 

(PROPAX)))))) 

("2. 1.1. 2"  (ASSERT)) 

->  (INST?) 

Figure  5:  PVS  Proof  of  Invariant  p  (Devillers  et  al.) 


ure  3  of  the  TAME  proof  of  Invariant  J5  illustrates,  a  TAME 
proof  can  be  understood  by  referring  only  to  the  specifica¬ 
tion  of  the  automaton  and  its  invariants,  without  rerunning 
it  in  the  PVS  proof  checker.  PVS  proofs  in  general  do  not 
have  this  property.  For  example,  one  must  step  through 
the  proof  in  Figure  5  with  the  PVS  proof  checker  to  de¬ 
termine  the  contributions  of  many  of  the  steps,  such  as 
(PROP),  (SKOSIMP*),  (HIDE  -1),  (INST?),  (REPLACE 
-2  :HIDE?  T),  and  (LIFT-IF)  in  the  first  column. 

The  PVS  encoding  of  state  invariant  lemmas  is  slightly  dif¬ 
ferent  from  the  TAME  encoding.  Most  invariants — those 
proved  by  induction — have  two  associated  lemmas:  the  first 
lemma  states  that  the  invariant  holds  in  start  states  and  is 
preserved  by  transitions,  and  the  second  (proved  trivially 
from  the  first)  states  that  the  invariant  holds  for  all  reach¬ 
able  states.  When  induction  is  not  required  in  the  proof — 
i.e.,  when  the  invariant  follows  from  other  invariants — only 
the  second  lemma  is  needed.  The  TAME  encoding  of 
every  state  invariant  lemma  is  equivalent  to  the  second  PVS 
lemma.  For  proofs  requiring  induction,  the  strategy 
AUTO.INDUCT  first  reduces  this  lemma  to  the  equiv¬ 
alent  of  the  first  PVS  lemma  before  performing  many  of  the 
standard  initial  proof  steps.  Thus,  the  TAME  proofs  by  in¬ 
duction  of  invariants  correspond  to  the  PVS  proofs  of  the 
first  associated  lemma  in  the  PVS  encoding. 

The  difference  between  corresponding  TAME  proofs  and 
PVS  proofs  is  illustrated  by  the  TAME  and  PVS  proofs 
for  J8  in  Figures  4  and  5.  Both  proofs  were  created  by  in¬ 
teractive  use  of  the  PVS  prover,  with  the  user  supplying  all 
the  information  in  the  proofs  (except  the  parts  in  italics). 
An  obvious  difference  between  the  proofs  is  the  number  of 
proof  steps:  the  TAME  proof  requires  the  user  to  supply 
only  14  steps,  while  the  PVS  proof  requires  the  user  to  sup¬ 
ply  111  steps.  The  two  proofs  also  have  different  structures. 
The  PVS  proof  tree  (see  Figure  5)  has  two  branches  at  the 
top  level,  with  the  second  divided  into  five  parts.  The  first 
branch  corresponds  to  the  base  case  of  the  induction  proof, 
while  the  five  parts  into  which  the  second  branch  divides  cor¬ 
respond  to  the  five  induction  cases — one  for  each  of  the  five 
actions  of  TIP  (see  Appendix  A).  By  contrast,  the  TAME 
proof  tree  (see  Figure  4)  has  three  top  level  branches. 

Although  the  two  proofs  have  different  structures,  some  re¬ 
lationships  can  be  found.  The  PVS  proof  clearly  has  re¬ 
peating  patterns;  the  TAME  strategies  take  advantage  of 
such  repeating  patterns  to  produce  higher-level  proof  steps. 
One  pattern,  which  appears  only  once  in  this  proof,  is  the 
application  of  another  invariant.  The  three  arrows  at  the 
bottom  of  the  second  column  of  the  PVS  proof  in  Figure  5 
mark  the  steps  that  apply  Invariant  I2  to  the  current  state 
(before  the  action)  and  the  skolem  constant  for  the  edge 
e  of  Invariant  1$.  In  the  TAME  proof  in  Figure  4,  this  is 
accomplished  by  the  proof  step  ( APPLY  JNV.LEMMA 
“2”  “e_theorem”)  in  the  second  proof  branch  (also  marked 
with  an  arrow).  Most  of  the  repeating  patterns  are  han¬ 
dled  by  either  AUTO  JNDUCT  or  TRY.SIMP.  For  ex¬ 
ample,  the  base  case  and  last  two  induction  cases,  whose 
proofs  are  “obvious”  to  a  human,  are  done  automatically  by 
AUTO.INDUCT.  Hence  the  three  top  level  branches  in 
TAME  proof  correspond  to  the  branches  “2.1”,  “ 2.2 ”,  and 
“2.3”  of  the  PVS  proof  (though  not  in  that  order)  repre¬ 
senting  the  three  nontrivial  action  cases. 


The  proof  execution  times  in  the  TIP  example  average  about 
three  times  as  long  for  the  TAME  proofs  as  for  their  corre¬ 
sponding  PVS  proofs  (e.g.,  the  longest  proof — of  three  in¬ 
variants  combined — took  37  seconds  for  TAME  vs  15  sec¬ 
onds  for  PVS3).  However,  the  relative  simplicity  and  clarity 
of  the  TAME  proofs  strongly  suggests  that  the  human  time 
needed  to  construct  the  proofs  with  TAME  is  considerably 
shorter  than  that  needed  to  construct  proofs  with  the  PVS- 
based  approach  of  [12]. 

Comparing  Specifications.  As  expected  of  two  indepen¬ 
dent  encodings  of  a  problem,  the  PVS  and  TAME  specifica¬ 
tions  have  rather  different  structures.  The  PVS  specification 
of  the  automaton  TIP  involves  a  large  set  of  automaton- 
specific  theories  with  a  complex  import  structure  having  sev¬ 
eral  (around  nine)  levels.  Moreover,  the  organization  of  the 
import  structure  is  at  least  partly  problem-specific.  Thus, 
how  one  would  use  the  same  methodology  to  specify  a  dif¬ 
ferent  I/O  automaton  in  PVS  is  not  completely  clear.  In 
contrast,  the  TAME  specification  of  TIP  is  essentially  a  sin¬ 
gle  automaton-specific  theory  that  imports  instantiations  of 
a  small  collection  of  generic  theories.  Only  one  of  these 
generic  theories — the  theory  states,  which  combines  the 
non-default  part  of  the  state  from  the  TAME  template  with 
the  default  part  associated  with  time  values — involves  the 
automaton  definition;  the  others  are  used  in  theorem  prov¬ 
ing  support.  Hence  unlike  the  PVS  specification,  the  TAME 
specification  of  the  automaton  involves  almost  no  layering 
of  definitions.  As  a  result,  the  TAME  specification  is  more 
easily  grasped  as  a  whole,  and  its  correspondence  to  the 
original  I/O  automaton  description  is  easier  to  see.  There 
are  additional,  automaton-specific  theories  associated  with 
the  TAME  specification  that  can  be  derived  in  a  standard, 
automatable  way  from  the  automaton  specification.  These 
theories  supply  lemmas  to  the  generic  TAME  strategies. 

The  PVS  and  TAME  specifications  of  TIP  also  differ  in  the 
way  they  capture  the  transitions.  In  the  PVS  specification, 
each  transition  is  described  using  the  combined  information 
from  the  precondition  and  effect  of  each  action.  In  TAME, 
the  preconditions  and  effects  of  actions  are  defined  sepa¬ 
rately.  In  a  few  instances,  some  information  from  the  pre¬ 
condition  is  needed  as  a  guard  in  the  definition  of  the  effect 
for  the  definition  to  pass  typechecking.  Experience  with 
many  examples  has  shown  that  in  practice,  this  rarely  hap¬ 
pens.  When  possible,  separating  the  precondition  and  effect 
of  an  action  provides  an  advantage  in  creating  understand¬ 
able  induction  proofs:  it  allows  one  to  determine  just  when 
the  precondition  is  important  in  the  induction  step  corre¬ 
sponding  to  that  action.  Thus,  it  allows  one  to  determine 
whether  a  specification  property  might  be  affected  when  a 
precondition  is  changed  in  the  specification. 

Beyond  Invariants:  Simulation  and  Refinement.  Be¬ 
cause  PVS  lacks  support  for  defining  a  general  automaton 
type  and  for  passing  theory  parameters  to  theories,  com¬ 
pletely  general  definitions  of  simulation  and  refinement  (see 
[22])  are  impossible  to  express  in  PVS.  For  this  reason, 
TAME  does  not  yet  include  specialized  support  for  proving 
simulations  or  refinements.  However,  the  PVS  specification 
of  TIP  does  include  a  definition  of  the  refinement  relation, 
using  the  most  convenient  general  form  that  can  currently 


3These  times  are  for  PVS  2.2  on  an  UltraSPARC-II. 


be  provided  with  PVS.4  In  addition,  the  PVS  proofs  for  TIP 
include  a  proof  that  TIP  is  a  refinement  of  another  automa¬ 
ton  called  SPEC.  In  this  respect,  the  PVS  specification  and 
proofs  have  an  advantage  over  the  TAME  specification  and 
proofs.  The  generic  theories  supporting  the  definition  of  re¬ 
finement  in  the  PVS  specification  can  almost  certainly  be 
adapted  for  use  with  a  new  TAME  “refinement”  template. 
Rather  than  use  this  approach,  however,  a  future  version  of 
TAME  will  use  PVS  support  for  theory  parameters  (to  be 
provided  in  a  future  version  of  PVS  [19])  to  provide  a  generic 
refinement  template  and  associated  proof  strategies. 

4.  SECOND  CASE  STUDY 

In  the  second  case  study,  the  third  author  applied  TAME 
first  to  examples  from  Romijn’s  solution  to  the  RPC-Memory 
Problem  [28,  27],  and  then  to  TIP  and  its  invariants  [12, 
11].  For  the  RPC-Memory  example,  this  required  specify¬ 
ing  three  I/O  automata  (called  Memory* ,  Memorylmp,  and 
Imp),  and  proving  24  associated  invariants.  In  the  case  of 
TIP,  she  used  TAME  to  specify  the  single  automaton  and  to 
check  the  proofs  of  the  15  invariants  for  which  hand  proofs 
were  supplied.  (Two  additional  TIP  invariants  for  which  no 
hand  proofs  were  given  were  later  proved  by  the  first  author 
using  TAME.)  Below,  we  first  describe  the  TIP  and  RPC- 
Memory  examples.  We  then  discuss  the  time  required  by  the 
third  author,  special  problems  she  had  to  solve,  the  extent 
to  which  the  TAME  strategies  were  sufficient  for  mechaniz¬ 
ing  the  proofs,  and  some  errors  in  specifications  and  proofs 
that  were  discovered  during  the  mechanization. 

The  Examples.  The  TIP  example  from  [12]  is  a  specifi¬ 
cation  and  analysis  of  the  leader  election  algorithm  forming 
the  core  of  the  tree  identify  phase  of  the  physical  layer  of  the 
IEEE  1394  high  performance  serial  multimedia  bus  protocol. 
The  goal  of  the  analysis  is  to  establish  the  property  “For 
an  arbitrary  tree  topology,  exactly  one  leader  is  elected.” 
Half  of  this  property  (“at  most  one  leader  is  elected”)  is 
proved  as  TIP  Invariant  Ji5  (see  Appendix  A).  The  RPC- 
Memory  problem,  which  was  posed  by  Broy  and  Lamport 
at  the  1994  Dagstuhl  Seminar  on  Reactive  Systems,  con¬ 
cerns  the  specification  of  a  memory  component  and  a  remote 
procedure  call  (RPC)  component  for  a  distributed  system 
and  the  implementation  of  both.  (The  TAME  specifications 
and  proofs  for  these  examples  can  be  found  at  the  URL 
http:  / / chacs.nrl.navy.mil  /  projects/tame. ) 

Time  Required.  The  third  author  required  approximately 
a  week  to  read  and  understand  earlier  TAME  specifications. 
These  specifications  include  auxiliary  theories,  which  are  de¬ 
rived  from  a  template  instantiation  and  currently  must  be 
generated  by  hand.  In  addition,  she  needed  about  a  day  to 
learn  how  to  use  TAME  to  obtain  a  proof. 

Once  these  initial  barriers  were  overcome,  specifying  Mem¬ 
ory*  in  TAME  and  creating  its  auxiliary  theories  required 
about  two  days,  and  the  proofs  of  its  three  invariants,  plus  a 
fourth  auxiliary  invariant,  required  only  a  few  hours.  Some 
of  this  time  was  used  to  discover  the  need  for  and  the  formu¬ 
lation  of  the  auxiliary  invariant.  Specifying  Memorylmp  in 
TAME  required  only  a  few  days.  Proving  its  12  invariants 
required  about  two  weeks.  The  time  required  to  prove  these 

4This  definition  makes  use  of  a  parameterized  automaton 
type  defined  in  a  theory  parameterized  by  the  action  and 
state  types. 


12  invariants  was  longer  for  a  combination  of  reasons.  First, 
the  proofs  of  these  invariants  were  more  complex  than  the 
proofs  of  the  Memory*  invariants.  Because  the  proof  of  one 
invariant  was  only  loosely  sketched,  some  time  was  required 
to  determine  all  of  the  facts,  including  an  additional  invari¬ 
ant  lemma,  required  in  its  proof.  Trying  to  understand  the 
scopes  of  the  quantifiers  in  one  of  the  invariants  led  to  a 
weaker  initial  formulation  of  the  invariant  that  was  insuffi¬ 
cient  for  the  proofs  of  later  invariants,  and  this  had  to  be 
rectified.  Finally,  the  third  author  encountered  some  situa¬ 
tions  in  which  the  TAME  strategies  had  to  be  supplemented 
by  special  knowledge  and  the  direct  use  of  PVS.  Once  appro¬ 
priate  improvements  were  made  to  TAME  (see  Section  5.3), 
she  was  able  to  complete  the  proofs.  After  her  experience 
with  Memory*  and  Memorylmp,  specifying  Imp  and  prov¬ 
ing  its  seven  invariants  took  only  three  days,  and  specifying 
TIP  and  proving  its  15  invariants  took  only  five  days. 

Special  Problems.  While  translating  I/O  automata  speci¬ 
fications  into  the  TAME  template  is  largely  straightforward, 
in  this  study,  creativity  was  needed  for  some  aspects  of  the 
translations.  For  the  most  part,  these  aspects  concerned 
type  definitions.  For  example,  the  specification  of  Memory- 
Imp  required  the  composition  of  several  I/O  automata  spec¬ 
ifications  into  a  single  TAME  specification.  In  such  compo¬ 
sitions,  output  actions  of  one  automaton  are  combined  with 
input  actions  of  another.  For  at  least  one  combined  action, 
creativity  was  required  in  defining  the  parameter  types  to 
make  an  output  action  and  an  input  action  compatible.  In 
addition,  several  state  variable  and  action  parameter  types 
in  the  RPC-Memory  automata  had  complex  subtype  rela¬ 
tionships.  The  third  author’s  original  definitions  of  these  re¬ 
lationships  in  TAME  led  to  several  improvable  TCCs  (type 
correctness  conditions  generated  by  the  PVS  typechecker). 
One  approach  to  making  the  TCCs  provable  is  to  include 
axioms  describing  the  subtype  relationships  in  the  specifi¬ 
cation.  Instead,  the  third  author  defined  the  types  as  ap¬ 
propriate  subtypes  of  a  PVS  datatype.  Doing  this  permits 
the  TCCs  to  be  proved  automatically  in  PVS  and  avoids  the 
possible  introduction  of  inconsistent  axioms. 

Another  case  in  which  some  sophistication  was  needed  to 
represent  an  I/O  automaton  in  TAME  was  in  a  step  of  Imp 
using  a  for  construct  to  simultaneously  update  a  set  of  vari¬ 
ables  whose  indices  satisfied  a  certain  predicate.  Because 
these  variables  could  not  be  enumerated,  representing  this 
step  in  TAME  required  the  use  of  the  LAMBDA  construct 
in  PVS. 

In  addition  to  the  information  required  in  the  TAME  tem¬ 
plate,  auxiliary  information  is  sometimes  needed.  For  the 
RPC-Memory  automata,  a  few  auxiliary  functions  and  pred¬ 
icates  defined  in  the  original  I/O  automata  specifications 
were  also  included  in  the  TAME  specifications.  For  TIP, 
a  few  auxiliary  results  about  data  structures  were  also  re¬ 
quired.  A  small  set  of  lemmas  about  the  relationship  be¬ 
tween  edges  and  their  reverse  edges  was  needed  to  mecha¬ 
nize  those  steps  in  hand  proofs  whose  justification  in  [11]  was 
“math”.  These  were  simple  enough  to  prove  using  GRIND, 
PVS’s  general  automatic  proof  step.0  In  addition,  a  subset 

°GRIND  fails  to  terminate  on  one  of  the  proofs  and  needs 
to  be  helped  by  APPLY- EXTENSION ALITY  in  another. 
Evidence  exists  that  these  complications  are  due  to  a  bug  in 
PVS.  We  have  reported  the  bug  to  the  PVS  implementors. 


of  the  theory  of  tree-structured  digraphs  was  needed  in  the 
proof  of  Invariant  /15.  Rather  than  using  the  full  theory 
developed  by  Devillers  et  al.,  the  third  author  simply  deter¬ 
mined  the  essential  fact  needed  about  such  digraphs — that 
they  are  connected — and  included  it  as  an  axiom.  Using  this 
axiom,  she  proved  several  auxiliary  invariants  needed  in  the 
proof  of  Iif,. 

Sufficiency  of  the  TAME  Strategies.  Once  improve¬ 
ments  to  the  TAME  strategies  (due  to  feedback  from  the 
third  author)  were  complete,  the  strategies  listed  in  Fig¬ 
ure  2  were  almost  sufficient  to  obtain  all  of  the  proofs  for 
the  RPC-Memory  example.  APPLY  JND.HYP  and  AP- 
PLYTEMMA  were  not  needed.  In  a  few  places,  new 
TAME  strategies  (INST_IN  and  SKOLEM_IN,  which  are 
described  in  Section  5.3)  and  the  PVS  steps  EXPAND  and 
INST  were  used. 

The  proofs  of  the  TIP  invariants  used  all  of  the  strate¬ 
gies  in  Figure  2,  together  with  INST_IN,  SKOLEM.IN, 
EXPAND,  and  INST;  in  addition,  the  PVS  step  SPLIT 
was  used  to  separate  threads  in  the  combined  proofs  of 
several  lemmas,  and  two  additional  TAME  steps,  COM- 
PUTE_POSTSTATE  and  DIRECTJNDUCTION 
were  required.  The  step  COMPUTE_POSTSTATE  was 
needed  to  introduce  facts  about  the  poststate  required  in 
a  proof  in  which  it  was  natural  to  refer  to  the  poststate 
in  a  supposition  introduced  with  SUPPOSE.  The  proof 
of  one  auxiliary  invariant  lemma  for  TIP  introduced  by 
the  third  author  required  induction  over  the  natural  num¬ 
bers,  but  not  over  the  reachable  states  of  TIP.  She  mecha¬ 
nized  this  proof  using  variants  of  the  PVS  SKOLEM  com¬ 
mand,  PVS’s  EXPAND,  INDUCT,  and  INST  commands, 
and  TAME’s  APPLY JNV.LEMMA  strategy.  The  step 
DIRECTJNDUCTION  was  developed  to  prove  invari¬ 
ants  whose  proof  requires  mathematical  induction  followed 
by  direct  (non-induction)  proofs  of  the  branches.  With  the 
aid  of  DIRECTJNDUCTION,  the  proof  can  be  mech¬ 
anized  using  PVS’s  EXPAND,  together  with  the  TAME 
strategies  APPLY  JNV.LEMMA,  SKOLEM  JN,  and 
APPLY  JND.HYP  (used  to  apply  the  mathematical  in¬ 
duction  hypothesis).  Whether  DIRECTJNDUCTION 
will  be  useful  in  other  examples  is  an  open  question. 

Specification  and  Proof  Errors  Discovered.  The  spec¬ 
ifications  and  proofs  of  both  the  RPC-Memory  and  TIP  ex¬ 
amples  were  very  carefully  done.  Thus,  the  third  author 
uncovered  only  a  few  errors.  Specifying  the  RPC-Memory 
automata  in  TAME  and  applying  the  PVS  typechecker  ex¬ 
posed  a  few  cases  of  incompleteness  and  inconsistency  in  the 
specifications.  For  example,  the  intended  types  of  certain 
constants  were  unclear,  and  there  was  a  type  inconsistency 
in  the  definition  and  use  of  one  function.  No  specification 
errors  were  found  in  the  TIP  example,  which  is  not  sur¬ 
prising,  since  this  example  had  already  been  proved  in  PVS. 
But  the  PVS  proofs  for  TIP  were  not  derived  from  the  hand 
proofs,  so  although  the  TIP  invariants  had  been  checked, 
their  hand  proofs  had  not  been  checked.  Using  TAME,  the 
third  author  discovered  a  few  cases  of  incorrect  inferences 
or  justifications  in  both  the  hand  proofs  for  TIP  and  the 
RPC-Memory  proofs.  She  was  able  to  correct  all  of  these 
problems  in  the  TAME  proofs,  usually  in  a  very  straight¬ 
forward  way,  and  in  one  case  by  identifying  and  proving  an 
auxiliary  invariant.  Thus,  like  Rudnicki  and  Trybulec  [29], 


she  found  that  Lamport-style  proofs,  though  very  structured 
and  detailed,  are  still  informal  and  as  a  result  may  contain 
incorrect  or  missing  details.  Her  results  led  to  corrections 
by  Romijn  and  Devillers  et  al.  in  both  the  specifications  and 
proofs  in  [28,  27,  11]. 

5.  DISCUSSION 

This  section  presents  several  observations  resulting  from  our 
case  studies.  First,  as  indicated  in  Sections  3  and  4,  TAME 
proofs  are  readily  constructed  from  hand  proofs  that  give 
sufficient  detail.  A  hand  proof  that  indicates  which  facts 
were  used  on  which  proof  branches  and  which  subcases  need 
to  be  considered  usually  provides  sufficient  detail;  details  of 
inferences  drawn  from  the  facts  are  normally  not  required. 
In  previous  applications  (e.g.  [3,  5]),  the  hand  proofs  mech¬ 
anized  with  TAME  were  English  language  proofs.  As  stated 
in  Section  4,  the  majority  of  the  proofs  mechanized  by  the 
third  author  using  TAME  were  Lamport-style  proofs.  These 
proved  to  be  as  straightforward  to  mechanize  in  TAME  as 
English  language  proofs.  Section  5.1  gives  an  example  of 
the  correspondence  between  a  Lamport-style  proof  and  the 
TAME  proof  derived  from  it.  Second,  as  noted  in  Sec¬ 
tions  2  and  3,  TAME  proofs  are  intended  to  be  understand¬ 
able  without  reference  to  the  PVS  proof  checker.  In  Sec¬ 
tion  5.2,  we  describe  how  TAME  proofs  can  actually  be  in¬ 
terpreted  as  English  language  proofs,  using  the  TAME  proof 
from  Section  5.1  as  an  example.  Finally,  several  improve¬ 
ments  were  made  to  TAME  as  a  result  of  the  third  author’s 
experience.  Section  5.3  discusses  these  improvements  and 
some  issues  they  raise. 

5.1  Constructing  TAME  Proofs 

The  proof  in  Figure  6  (provided  to  the  reader  as  an  aid) 
describes  in  English  the  complete  TAME  proof  (see  Figure  7) 
of  TIP  Invariant  I4.  As  an  illustration  of  how  a  TAME  proof 
can  be  obtained  from  a  Lamport-style  proof,  Figures  7  and  8 
show  the  correspondence  between  the  TAME  steps  and  the 
relevant  steps  from  a  Lamport-style  proof  of  Invariant  I4. 
These  relevant  steps  are  shown  in  Figure  8,  which  contains 
the  single  branch  of  the  hand  proof  that  TAME  found  to 
be  nontrivial;  the  remainder  of  the  Lamport-style  proof  was 
done  automatically  by  TAME. 

To  understand  the  relationship  between  the  two  kinds  of 
proofs,  we  can  compare  the  Lamport-style  and  TAME  proofs 
of  1. 1  in  Figures  8  and  7.  In  the  Lamport-style  proof  in 
Figure  8,  the  values  s  and  t  represent  the  prestate  and 
poststate  in  the  induction  step,  and  the  values  /,  g,  and 
v'  are,  respectively,  the  skolem  constants  for  the  quanti¬ 
fied  variables  e,  /,  and  v  in  I4,  which  TAME  automatically 
names  e_theorem,  f_theorem,  and  v_theorem.  The  action 
C-KNOWN(v)  in  the  Lamport  proof  corresponds  to  the  ac¬ 
tion  children_known(childV_action)  in  the  TAME  proof; 
the  name  childV_action  is  constructed  automatically  by 
TAME  from  the  name  of  the  formal  parameter  childV  of 
children_known.  We  added  annotations  (see  the  right-hand 
column  of  Figure  7)  to  the  TAME  proof  to  show,  for  each 
of  its  steps  or  branches,  the  step  of  the  Lamport  proof  con¬ 
taining  a  corresponding  inference  or  justification.  For  ex¬ 
ample,  the  appeal  “by  IH”  to  the  inductive  hypothesis  at 
step  <  3.1  >  in  the  Lamport-style  proof  is  handled  au¬ 
tomatically  by  TAME’s  AUTOJNDUCT  strategy  since, 
for  this  proof,  the  correct  instantiation  of  its  variables  is  the 


To  prove:  For  every  reachable  state  s, 

for  all  edges  e  and  f  and  every  vertex  v, 
if  target  (e)  =  target  (f)  =  v  and  e  4  f, 
then  init (v)  or  child  (e)  or  child  (f). 

Proof:  The  proof  is  by  induction.  The  assertion  is  trivial  for  the  base  case,  i.e.,  when  s 
is  an  initial  state.  For  each  action  of  TIP,  it  remains  to  prove  the  corresponding  induction 
case,  i.e.,  that  the  assertion  is  preserved  by  that  action.  Only  one  of  the  induction  cases  is 
nontrivial:  the  case  of  the  action  children_known  (childV) . 

Thus,  consider  the  case  when  the  action  is  children_known  (childV) .  Let  the 
value  of  the  parameter  childV  of  children_known  be  childV_action.  Let 
the  state  before  this  action  be  prestate.  Let  the  edges  e  and  f  and  the  vertex  v  be 
e_theorem,  f_theorem,  and  v_theorem.  Consider  separately  two  cases.  Sup¬ 
pose  first  that  v_theorem=  childV_action.  In  this  case,  introduce  the  fact  that 
init (childV_action,  prestate)  a 
V e : tov (childV_action)  ,  f : tov (childV_action) . 

child (e, prestate)  v  child (f, prestate)  v  e  =  f 
by  appealing  to  the  specific  precondition  of  children_known  (childV_act ion) 
in  the  state  pre state.  Instantiating  the  second  part  of  this  precondition  with 
e_theorem  and  f_theorem,  the  remainder  of  the  proof  in  this  case  is  now  obvious. 
The  fact  that  e_theorem  and  f_theorem  belong  to  the  subtype 
tov  (childV_action)  of  the  type  Edges  is  also  obvious.  The  proof  in  the  case 
v_theorem  ^  childV_action  is  obvious. 


Figure  6:  English  translation  of  TAME  proof  of  I4 


Inv_4(s: states):  bool  = 

(FORALL  (e,f:Edges,  v: Vertices): 

(target(e)=v  and  target(f)=v  and  not(e=f)) 

=  >  (init(v,s)  or  child(e,s)  or  child(f,s))) 


(“”  (AUTOJNDUCT) 

;;  Case  children _known(childV .action) 

(SUPPOSE  “v_theorem  =  child V_action”) 

((“1”  ;;  Suppose  v. theorem  =  childV  .action 
(APPLY_SPECIFIC_PRECOND) 

;;  Applying  the  precondition 
;;  init  (childV .action,  prestate) 

;;  AND 

;;  (FORALL  (e:  tov  (childV -action)): 

;;  FORALL  (f:  tov  (childV -action)): 

;;  child(e,  prestate)  OR 

;;  child (f,  prestate)  OR  e  =  f) 

(INST  “specific-precondition_part_2” 
“e_theorem”  “f_theorem”) 

((“1.1”  (TRY.SIMP) ) 

(“1.2”  (TRY _SIMP)) 

(“1.3”  (TRY_SIMP))jJ 
(“2”  ;;  Suppose  not  [v .theorem  =  childV. action] 
(TRY.SIMP) ))) 


<  3  >,<3.1  >,<3.2  >, 

<  3.2.1  > 

<  3.2.2  > 

<  3.2.3  > 

<  3.2. 3.1  > 


<  3.2. 3.2  >,<  3.2.3.3> 

<  3.2. 3.1  > 

<  3.2.3.1  > 

<  3.2.4  > 

<  3.2.4.1  >,<  3.2.4.2  > 

<  3.2.5  >,<  3.3  > 


Figure  7:  Complete  TAME  proof  (verbose)  of  I4 


I4  =  Ve,/,t;trtrpet(e)  =  target(f)  =  v  A  e//^-  init(v )  V  child[e]  V  child[f] 


<3>  Assume  a  =  C-KNOWN(v),  v  e  V 
<3.1>  .  s\=I4 

<3.2>  .  Take  arbitrary  f,g,v'  such  that 

target(f)  =  target(g)  =  v  A  g  ^  / 
<3.2. 1>  .  .  s  |=  init( v')  V  child[f\  V  child[g] 
<3.2.2>  .  .  Case  distinction  on  v  =  v 

<3.2.3>  .  .  Assume  v  =  v 

<3.2.3.1>  .  .  .  s  |=  child[f\  V  child[g] 

<3.2.3.2>  .  .  .  t  |=  child[f]  V  child[g] 

<3.2.3.3>  .  .  .  t  |=  init(v)  V  child[f]  V  child[g] 
<3.2.4>  .  .  Assume  ->(v'  =  v) 

<3.2.4. 1>  .  .  .  s  |=  init(v')  V  child[f]  V  child[g] 
<3.2.4.2>  .  .  .  t  |=  init(v')  V  child[f]  V  child[g] 

<3.2.5>  .  .  t  |=  init(v')  V  child[f]  V  child[g] 

<3.3>  .t  \=  I4 


(by  IH) 


(pre.  C.KNOWN{v)  and  /,  g  €  to(v)) 

(eff.  C-KNOWN(v)  does  not  change  child) 


(by  <3.2.1>) 

(eff.  C-KNOWN(v)  does  not  change  child 
or  init[v]  by  <3.2.4>) 

(def.  I4) 


Figure  8:  Nontrivial  branch  of  Lamport-style  proof 
of  I4 


skolem  constants.  The  only  steps  the  TAME  user  must  sup¬ 
ply,  besides  TRY_SIMP,  are  the  SUPPOSE  for  the  case 
distinction  at  step  <  3.2.2  >  and  the  APPLY  _SPECI- 
FIC_PRECOND  and  INST  corresponding  to  application 
of  the  precondition  to  /  and  g  at  step  <  3. 2. 3.1  >.  Check¬ 
ing  that  /  and  g  are  of  type  to{v)  is  handled  by  proving 
the  TCCs  generated  by  PVS  as  the  result  of  the  instanti¬ 
ation  step  INST — this  is  accomplished  by  the  proof  steps 
TRYJ3IMP  at  “1.2”  and  “1.3”  in  the  TAME  proof.  In¬ 
troducing  the  effect  of  the  action  and  setting  up  Invariant 
1, 4  in  the  poststate  as  a  proof  goal  are  both  handled  auto¬ 
matically  in  the  TAME  proof  by  AUTOJNDUCT,  and 
appeals  to  previous  proof  steps  are  handled  automatically 
in  the  TAME  proof  by  the  final  TRYJ3IMP. 

5.2  Explaining  TAME  Proofs 

Because  the  meanings  of  TAME  proof  steps  are  essentially 
independent  of  the  proof  state  current  at  the  time  they  are 
executed  by  the  PVS  proof  checker,  TAME  proofs  can  be 
understood  from  their  saved  scripts  by  referring  to  the  orig¬ 
inal  specification  and  by  knowing  the  conventions  TAME 
uses  for  skolemization  and  instantiation.  Thus,  given  the 
TAME  proof  of  Figure  7,  it  is  fairly  straightforward  to  derive 
the  equivalent  English  language  proof  in  Figure  6.  Knowl¬ 
edge  of  TAMF's  conventions  about  skolemization  is  used  in 
specializing  the  action  parameter  childV  to  childV_action, 
and  s,  e,  f,  and  v  in  the  theorem  to  prestate,  e_theorem, 
f_theorem,  and  v_theorem.  One  convention  about  instanti¬ 
ation  is  used  in  the  INST  command  in  the  TAME  proof:  a 
precondition  in  the  form  of  a  conjunction  is  broken  down  into 
‘Apart  J” ,  “_part_2” ,  and  so  on,  in  order.  A  second  conven¬ 
tion  about  instantiation  is  reflected  in  the  English  transla¬ 
tion  in  Figure  3  of  the  APPLY  JNV.LEMM A  step  in  the 
TAME  proof  in  Figure  4:  unless  a  state  argument  is  given, 
the  invariant  lemma  is  applied  to  the  state  prestate.  One 
additional  question  that  arises  in  interpreting  the  TAME 
proof  in  Figure  7  is  why  the  INST  step  in  the  proof  results 
in  three  subgoals  instead  of  one.  When  extra  subgoals  from 
an  INST  occur,  PVS  has  generated  one  or  more  TCCs  as 
extra  proof  branches,  requiring  the  user  to  show  that  values 
used  in  the  instantiation  have  the  correct  types. 

Aside  from  the  problem  with  possible  TCCs,  the  deriva¬ 
tion  of  an  English  language  proof  from  a  TAME  proof  is 
straightforward  enough  to  be  automatable,  and  in  fact,  we 
have  recently  implemented  a  prototype  translator  of  saved 
TAME  proofs.  Note  that  the  TAME  proof  in  Figure  7  is  a 
verbose  TAME  proof,  in  contrast  to  the  Son-verbose  TAME 
proof  in  Figure  4.  Thus,  details  such  as  the  actual  fact 
introduced  by  APPLY_SPECIFIC_PRECOND  in  Fig¬ 
ure  7  can  be  incorporated  into  the  English  version.  Had  the 
proof  in  Figure  4  been  verbose,  the  actual  fact  introduced 
by  APPLY  JNV.LEMM A  would  have  been  displayed  in 
the  TAME  proof  (as  well  as  the  facts  introduced  by  each 
of  the  three  uses  of  APPLY  .SPECIFIC  J’RECOND). 
An  alternative  to  translating  TAME  proofs  from  their  saved 
scripts  to  obtain  an  English  language  version  is  to  create 
an  English  language  version  simultaneously  with  the  TAME 
version.  Implementing  this  technique  would  allow  even  more 
detail  to  be  incorporated  in  the  English  version,  if  desired, 
and  would  better  facilitate  interpreting  extra  TCC  subgoals 
in  English. 


5.3  Improvements  Made  to  TAME 

Several  improvements  were  made  to  the  template,  the  strate¬ 
gies,  and  the  supporting  theories  of  TAME  as  the  result  of 
feedback  from  the  third  author.  The  first  improvement  gen¬ 
eralizes  the  template.  Improvements  to  the  strategies  have 
made  TAME  more  user-friendly  by  reducing  the  amount 
of  low-level  reasoning  associated  with  certain  proof  steps. 
Improvements  to  the  supporting  theories  extend  the  scope 
of  the  high-level  reasoning  supported  in  TAME.  We  dis¬ 
cuss  these  improvements  below,  along  with  some  issues  they 
raise. 

Improving  the  Template.  The  base  case  of  induction 
proofs  corresponding  to  the  start  states  is  usually  trivial 
to  prove.  The  strategy  AUTOJNDUCT  is  designed  to 
prove  the  base  case  automatically,  when  possible.  Although 
none  of  the  TAME  templates  enforce  any  condition  on 
the  form  of  the  start  state  predicate  start,  the  automatic 
proof  of  the  base  case  by  AUTOJNDUCT  works  best  if 
start (s)  is  expressed  as  an  equality  s  =  <start-state>, 
where  <start-state>  is  a  record  value.  In  previous  appli¬ 
cations  of  TAME,  each  automaton  had  a  single  start  state, 
and  thus  the  convention  was  that  <start-state>  was  an 
explicit  record  giving  the  initial  values  of  all  state  variables. 

In  the  KI’U  Memory  example,  the  third  author  encountered 
an  automaton  in  which  the  start  state  was  not  unique:  initial 
values  were  given  for  only  some  of  the  basic  state  variables. 
She  therefore  developed  a  new  template  convention  for  the 
start  state,  in  which  <start-state>  is  a  record  with  its  time- 
related  components  assigned  the  standard  initial  values  and 
its  basic  component  (representing  the  basic  state  variables) 
assigned  its  “old”  value  updated  with  values  for  those  vari¬ 
ables  whose  initial  values  are  specified.  This  is  easily  done 
using  the  PVS  construct  WITH  for  updating  records  and 
functions  and  has  the  effect  of  leaving  the  non-updated  vari¬ 
ables  of  the  basic  state  unspecified,  as  desired.  Moreover, 
the  strategy  AUTOJNDUCT  works  just  as  well  for  prov¬ 
ing  base  cases  with  the  new  conventional  form  for  start  (s) 
as  it  did  with  the  old  one. 

Improving  the  Strategies.  As  noted  in  Section  4,  the 
third  author  had  difficulty  translating  a  few  of  the  steps 
from  hand  proofs  into  TAME.  One  such  step  was  the  ap¬ 
plication  of  an  invariant  lemma  to  the  poststate  of  a  tran¬ 
sition  in  an  induction  step.  The  default  used  by  the  TAME 
step  APPLY JNV.LEMM A  is  to  apply  the  lemma  to 
prestate.  TAME  previously  represented  the  poststate  as 
trans  (<action> , prestate) ,  where  <action>  is  the  action 
of  the  induction  step,  and  maintained  among  the  hypothe¬ 
ses  the  fact  that  trans  (<action>, prestate)  is  reachable, 
to  facilitate  application  of  invariant  lemmas  to  the  post¬ 
state.  However,  this  representation  of  the  poststate  com¬ 
plicated  applying  an  invariant  lemma.  Not  only  did  the 
user  have  to  supply  trans  (<action> , prestate)  as  an  ar¬ 
gument  to  APPLY JNV .LEMMA,  where  <action>  it¬ 
self  could  be  an  expression  with  parameters,  but  after  doing 
this,  the  user  had  to  explicitly  expand  the  transition  func¬ 
tion  trans.  The  third  author’s  difficulties  inspired  improve¬ 
ments  to  AUTOJNDUCT  and  APPLY  JNVJEMMA 
that  hide  this  complexity  from  the  user.  The  term 
trans  (<action> , prestate)  is  now  represented  simply  as 
poststate,  and  to  apply  an  invariant  lemma  to  the  post- 


*  1.  length(emptylist)  =  0 

2.  V  Lrlist.  length(L)  =  0  =>  L  =  emptylist 

3.  V  n:nat,  e:element,  L:list.  length(L)  =  n  =>  length(cons(e,L))  =  n+1 

*  4.  V  eielement,  L:list.  L  =  emptylist  =>  length(cons(e,L))  =  1 

*  5.  V  n:nat,  e:element,  L:list.  L  ^  emptylist  a  length(L)  =  n  =>  length(cdr(L))  =  n-1 

*  6.  V  n:nat,  e:element,  L:list.  L  ^  emptylist  a  length(L)  <  n  =>  length(cdr(L))  <  n-1 
7.  V  L:list.  (length(L)  <  0)  =  FALSE 


Figure  9:  Rewrite  rules  for  lists  used  by  TAME 

state,  the  user  simply  applies  APPLY  JNVJEMMA  to 
the  argument  poststate  and  any  other  arguments  to  the 
lemma. 

As  noted  in  reference  [4],  the  inability  of  the  user  to  instan¬ 
tiate  or  skolemize  with  respect  to  embedded  quantifiers  in 
PVS  sometimes  makes  it  difficult  to  follow  the  structure  of 
a  hand  proof  using  PVS.  The  third  author  encountered  this 
problem  in  some  proofs  of  the  RPC-Memory  example.  To 
address  the  problem,  two  new  strategies,  called  INSTJN 
and  SKOLEM  JN,  were  added  to  TAME  to  approximate 
internal  instantiation  and  skolemization.  These  strategies 
perform  automated  simplification  in  an  attempt  to  handle 
the  non-quantified  parts  of  a  formula,  and  then  use  the  stan¬ 
dard  PVS  proof  steps  INST  and  SKOLEM.  Although  some 
wasteful  proof  branching  can  result  (this  happened  with 
one  RPC-Memory  lemma),  this  approach  handles  embed¬ 
ded  quantifiers  well  in  many  cases. 

Improving  the  Supporting  Theories.  The  state  vari¬ 
ables  used  in  I/O  automata  specifications  do  not  always 
have  simple  types.  For  example,  some  automata  from  the 
RPC-Memory  example  use  state  variables  that  must  be  rep¬ 
resented  as  “datatypes”  using  the  PVS  DATATYPE  con¬ 
struct.  As  noted  in  Section  2,  TAME  supports  “obvious” 
reasoning  about  datatypes  using  auxiliary  theories  gener¬ 
ated  from  a  template  instantiation.  Previous  to  the  third  au¬ 
thor’s  use  of  TAME,  these  auxiliary  theories  contained  only 
lemmas  to  support  reasoning  about  the  datatype  actions.6 
Because  of  the  additional  datatypes  used  in  the  RPC-Mem- 
ory  automata,  the  auxiliary  theories  now  include  lemmas 
from  all  datatypes  in  a  template  instantiation. 

In  the  specification  of  the  automaton  TIP  from  [12]  (see 
Appendix  A),  the  type  of  the  state  variable  mq(e),  where  e 
is  an  edge,  is  defined  to  be  Bool*,  that  is,  a  list  of  Booleans. 
Several  of  the  TIP  invariant  lemmas  involving  mq(e)  require 
reasoning  about  lengths  of  lists.  Because  PVS  has  a  built-in 
type  list[T],  where  T  is  a  type  parameter,  it  is  reasonable 
to  add  auxiliary  lemmas  to  support  reasoning  about  lengths 
of  lists.  Figure  9  shows  the  set  of  lemmas  used  as  rewrite 
rules  for  lists  in  TAME.  Those  rules  with  an  asterisk  were 
actually  applied  by  TAME  in  proving  the  TIP  invariants. 
The  PVS  proof  in  Figure  5  contains  several  instances  of  the 
PVS  command  ‘(EXPAND  “length”)’;  these  mark  places 
where  simple  reasoning  about  length  is  occurring.  With  the 
rules  in  Figure  9,  the  TAME  user  does  not  need  to  guide 
PVS  through  this  reasoning. 

While  one  might  argue  that  rewrite  rules  for  lists  should  be 
standard  in  TAME  because  list[T]  is  a  standard  type  in 


6For  LV  timed  automata,  there  are  also  lemmas  for  the 
datatype  time. 


PVS,  there  are  many  examples  in  which  state  variables  have 
other  complex  types,  as  we  discovered  in  applying  TAME  to 
some  of  the  invariant  lemmas  of  [14].  For  reasons  of  proof 
efficiency,  the  number  of  rewrite  rules  that  are  always  ac¬ 
tive  should  be  limited  to  those  that  are  relevant,  Thus,  a 
practical  approach  for  handling  “obvious”  reasoning  about 
complex  types  is  to  use  a  library  of  PVS  theories  containing 
the  lemmas  needed  to  support  such  reasoning.  Such  theo¬ 
ries  need  to  be  developed  with  care;  we  do  not  guarantee 
the  theory  in  Figure  9  to  be  the  best  theory  to  support  ob¬ 
vious  reasoning  about  lengths  of  lists.  The  extent  to  which 
existing  libraries  developed  by  other  members  of  the  PVS 
user  community  would  be  useful  in  TAME  is  still  to  be  de¬ 
termined. 

6.  RELATED  WORK 

An  increasing  number  of  proof  assistants,  including  assis¬ 
tants  for  the  Duration  Calculus  [30],  for  the  TRIO  logic 
[1],  and  for  proving  invariant  properties  of  DisCo  specifi¬ 
cations  [17],  use  PVS  as  the  underlying  prover.  The  Du¬ 
ration  Calculus  and  TRIO  assistants  support  proofs  using 
steps  from  particular  logics.  The  DisCo  assistant  supports 
proofs  of  properties  of  DisCo  specifications,  using  Lamport’s 
Temporal  Logic  of  Actions,  with  specialized  PVS  strategies 
generated  by  a  compiler.  These  strategies,  though  uniform 
in  concept,  are  specific  to  each  given  application.  A  simi¬ 
lar  approach  was  used  in  an  earlier  version  of  TAME;  PVS 
enhancements,  especially  the  documentation  of  the  inter¬ 
nal  structure  of  PVS  sequents,  have  allowed  us  to  make  the 
TAME  strategies  more  generic. 

Several  researchers  have  applied  mechanical  theorem  provers 
to  LV  timed  automata  or  I/O  automata.  In  addition  to  the 
application  of  PVS  described  in  [12],  reference  [20]  describes 
how  the  Larch  theorem  prover  LP  was  used  to  prove  proper¬ 
ties  of  several  protocols  specified  as  LV  timed  automata,  and 
reference  [26]  describes  a  verification  environment  for  I/O 
automata  based  on  Isabelle;  like  [12],  both  include  simula¬ 
tion  proofs  as  well  as  proofs  of  invariants.  In  addition,  [26] 
develops  a  detailed  metatheory  for  I/O  automata.  TAME 
has  an  advantage  over  Larch  and  Isabelle:  it  produces  com¬ 
pact,  informative  proof  scripts.  Although  Larch  provides 
detailed  proof  scripts  with  some  information  on  the  content 
of  a  proof.  Larch  does  not  support  the  matching  of  high 
level  natural  proof  steps  with  user-defined  strategies,  nor 
the  automatic  documentation  of  a  proof  through  comments 
provided  by  TAME.  While  Isabelle  tactics  perform  some  of 
the  services  of  the  TAME  strategies  [26],  Isabelle  does  not 
save  proof  scripts  for  completed  proofs. 

A  toolset  has  been  developed  that  provides  an  automatic 
translator  from  the  IOA  language  for  I/O  automata  to  Larch 
specifications  and  an  interface  to  the  Larch  theorem  prover 
LP  [15].  This  toolset  will  eventually  include  a  similar  trans¬ 
lator  to  PVS  that  is  being  developed  by  Devillers  and  Vaan- 
drager;  a  prototype  now  exists  [13].  TAME  currently  has 
a  prototype  translator  from  specifications  in  the  SCR  lan¬ 
guage  to  TAME  specifications  [6],  and  an  automatic  trans¬ 
lator  from  IOA  specifications  is  planned. 


7.  CONCLUSION 

In  [24],  Miller  discusses  several  major  problems  encountered 
in  the  AAMP5  project,  in  which  PVS  was  used  to  prove  the 
correctness  of  a  set  of  microcode  instructions.  Two  problems 
were  how  to  organize  the  specification,  and  how  to  structure 
complex  proofs.  He  also  notes  that  the  learning  curve  in  this 
project  was  very  steep,  that  many  supporting  theories  had 
to  be  developed,  and  that  the  robustness  of  proofs  became 
a  concern  when  specifications  were  modified. 

Within  its  domain  of  application,  TAME  solves  most  of 
these  problems.  In  particular,  it  provides  templates  to  or¬ 
ganize  specifications  of  automata,  high  level  proof  steps  de¬ 
signed  to  make  proof  structures  more  understandable,  and 
supporting  theories  appropriate  to  the  domain.  The  third 
author’s  experience  with  TAME  lends  support  to  our  belief 
that  the  learning  curve  for  TAME  is  much  less  steep  than 
that  for  the  direct  use  of  PVS.  TAME  proofs  tend  to  be  fairly 
robust,  because  they  use  high  level  proof  steps  that  do  not 
depend  on  details  of  the  sequent  in  the  current  proof  goal. 
(This  dependence  is  present  in  several  places  in  the  PVS 
proof  in  our  first  case  study.)  In  addition,  TAME  proofs 
are  usually  easy  to  modify  when  a  change  in  a  specification 
requires  some  changes  in  a  proof. 

In  [24],  Miller  also  notes  that  productivity  in  the  AAMP5 
project  required  the  same  individuals  to  serve  as  both  do¬ 
main  experts  and  PVS  experts.  Because  TAME  proofs  can 
be  understood  separately  from  PVS,  we  believe  that  TAME 
can  provide  a  way  to  allow  domain  experts  to  understand 
the  results  of  a  verification  without  becoming  PVS  experts, 
and  to  communicate  high-level  proof  outlines  to  PVS  (or 
TAME)  experts  that  can  be  easily  checked  in  TAME.  This 
has  been  demonstrated  to  some  extent  by  our  previous  ex¬ 
perience  with  TAME  and  by  the  third  author’s  experience 
with  the  RPC-Memory  example. 

Thus,  we  believe  that  specialized  interfaces  such  as  TAME 
can  solve  many  of  the  problems  associated  with  introducing 
the  use  of  PVS  into  industrial  practice.  This  is  consistent 
with  the  point  of  view  of  Crow  and  Di  Vito  [10],  who  state 
in  that: 

Applying  formal  methods  “right  out  of  the  box” 
is  difficult.  Tailoring  the  methods  to  the  appli¬ 
cation  at  hand  is  both  necessary  and  desirable. 

As  noted  in  Section  2,  TAME  is  based  on  template  specifi¬ 
cations  for  given  system  models,  standard  supporting  the¬ 
ories,  and  special  strategies  to  implement  reasoning  steps 
appropriate  to  the  models.  With  an  appropriate  automatic 
specification  translator,  a  specialized  interface  can  also  al¬ 
low  developers  to  create  specifications  in  an  environment 
familiar  to  them.  For  TAME,  such  a  translator  has  been 
developed  for  specifications  created  in  the  SCR  toolset  [6]. 
We  believe  that  the  same  methods  can  be  followed  to  cre¬ 
ate  specialized  interfaces  in  other  application  domains.  In 
fact,  similar  methods  were  used  to  some  extent  in  the  other 
PVS-based  proof  assistants  discussed  in  Section  6.  An  open 
question  is  whether  specialized  interfaces  such  as  TAME  can 
be  developed  to  address  the  needs  of  practitioners  working 
in  different  application  domains. 
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APPENDIX 

A.  THE  I/O  AUTOMATON  tip  FROM  [12] 

TIP 


Internal:  ADD -CHILD,  CHILDREN -KNOWN,  RESOLVE-CONTENTION,  ACK 

Init:  Vu,  e  :  init[v\ 

A-icontention[v] 
A->root[v] 
A->child[e] 

A  mq[e]  =  empty 


Output:  ROOT 

State  Variables:  init  :  V  — >  Bool 

contention  :  V  — >  Bool 
root  :  V  -¥  Bool 
child  :  E  — >  Bool 
mq  :  E  — >  Bool* 

Actions: 

ADD-CHILD(e  :  E) 

Precondition  : 

A  init  [ta  rget  (e)] 

A mq[e]  ^  empty 
Effect  : 

child[e]  :=  1 
mq[e]  :=  tl(m<j[e]) 

RESOLV E -CONTENTION^  :  E) 
Precondition  : 

A  contenti  on[source(e)] 

A  contenti  on[ta  rget  (e)  ] 

Effect  : 

child[e]  :=  1 

contention[ source(e)]  :=  0 
contention[ target(e)]  :=  0 

CHILDREN  JCNOWN( v  :  V) 
Precondition  : 

A  init  [u] 

AVe,  /  €  to(ti)  :  child[e]  V  child[f]  V  e  =  / 
Effect  : 


ACK{e  :  E) 

Precondition  : 

A  ^ -i  init  [t  a  rget  ( e)] 

A mq(e)  ^  empty 
Effect  : 

contenti on[ta rget (e)]  :=  -ihd(mq[e]) 
mq[e]  :=  tl(mg[e]) 

ROOT(v  :  V) 

Precondition  : 

A~>init[v] 

A -i  contenti  on[v\ 

A -i  root  [w] 

AVe  G  to(v)  :  child[e] 

Effect  : 
root[v\  :=  1 


init[v\  :=  0 

fore  €  from(tj)  domg[e]  :=  append(c/iiZd[e_  ],  mq[e]) 


TIP  Invariant  Ii  5  = 

(3tA/e  6  to(ti)  :  child[e])  —¥  (3!uVe  €  to(v)  :  child[e]) 

“There  is  at  most  one  node  for  which  all  incoming  links  are 
child  links.  ” 


